The Trusted Platform Module (TPM) chip is hardware typically installed as part of a computing device such as a laptop or desktop PC (and potentially in devices such as cell phones and PDAs). The TPM chip is used to provide trusted information on the identity and internal state of the computing device in order to validate the current hardware and software. Current implementations of the TPM architecture assume physical bindings between the TPM chip and a single hardware platform. The TPM chip is typically installed as part of a system (e.g. a chip on the PCI bus) and is used to provide trusted information on the identity and internal state of the device and to store cryptographic secrets and identities. This is expected to increase the ability to defend against viruses and other security attacks and to verify the installed software. The TPM chip in personal computers (laptops, desktop PCs) is already on the market and their use is increasing rapidly. Moreover, security systems utilizing TPM functionality are beginning to be deployed for applications which require enhanced levels of data security, such as medical record handling. The most common implementation of a TPM is a chip physically attached to a computer. The TPM functionality is accessed by software using a well defined command set. Through this command set, the TPM chip provides cryptographic functionality such as encrypting, signing, key generation and random number generation. The TPM chip can also store a limited amount of information in a non-volatile-space.
Additionally, the TPM chip contains a set of extensible Platform Configuration Registers (PCRs). PCRs are used to store measurements on the current status of the platform. PCRs are reset when the system powers up and can only be extended, but never directly modified. The measurements stored in the PCRs are performed by each parent before handing off control to other components. The first measuring entity of the platform is trusted by default, as it is not previously measured by any other entities. This early measuring entity is called the Core Root of Trust (CRT) for measurement. For security, the CRT may be stored inside the TPM chip itself. After the first measurement by the CRT all software entities launched are expected to continue the chain of trust by extending the PCR registers before launching any other software. Each measurement is recorded and can be cryptographically verified using the PCRs by a verification party. The action of sending these measurements to a verification party for verification is called attestation.
The Trusted Computing Group (TCG) has defined open standards for hardware-based system security. The specifications provided by the TCG center around the TPM chip and its functionality. More specifically, the TCG bases its standards on the TPM chip as the hardware root-of-trust. While the TCG's standard is based on a physical TPM chip, there has been some work done with software based TPM emulators. Software based TPM emulators mimic the behavior of a real TPM chip as seen from the driver interface. These software based TPM emulators are typically installed and executed in and on the device that is running the application that needs the TPM functionality provided by the software based TPM emulator.
The mobile working group of the TCG is developing standards for implementing TPM functionality on portable devices. Current implementations of TPM functionality rely on the use of the same platform because the bindings between the system and the TPM chip are physical. Thus, keys and cryptographic identities are stored locally in the TPM and possibly bound to the current state of the system. In order to overcome this limitation, the TCG provides migration features as part of the standard in order to import and export keys and identities if they are marked as migratable. However, the time consumption and logistic problems related to acquiring the authorization to port to an unknown but trusted platform makes it unfeasible for jobs that require constant mobility between different platforms. Additionally, mobile workers may be required to work with unknown platforms where secrets cannot be changed and internal states cannot be modified. This undermines the security features that the TPM might provide for the mobile worker, and in some instances may even prevent the platform from being utilized at all if the attestation is performed remotely.
Another potential solution is to simply export the TPM functions and implementation application program interface (API) to an external mobile cryptographic coprocessor (e.g. a smart card). This external device might have some sort of secure storage, providing the solution for mobile keys and identities. This approach, however, is not compatible with the TCG standards for several reasons (e.g., sealing to the platform state is not possible, as the state of the platform will change for each system where the device is connected). Moreover, the measurements and attestation which are a core part of the TCG standards could not be met by this simple architecture, because the underlying trusted computing base will most likely be unknown. Additionally, the existence of another TPM on the system connected to the device may create conflicts which will bring the machine to an incorrect state.
Yet another solution may be to use an external TPM that may provide the TPM functions and implementation API and possibly secure storage. However, for security applications this approach is not compatible with the TCG standards for several reasons (e.g., sealing to the platform state is not possible, as the state of the platform will change for each system where the device is connected). Another possible problem is that the underlying Trusted Computing Base (TCB) will most likely be unknown. Finally, the existence of another TPM on the system where the external TPM is to be connected may, in some circumstances, create a conflict of operation.
The use of virtual machine monitors (VMM) (also called hypervisors) is exploding and their use is now pervasive in distributed environments and servers. For example, stock operating systems like Redhat include the Xen hypervisor by default. A hypervisor allows other operating systems to run in parallel on top of it and offers a strong isolation between the running operating systems. In the field of portable environments a notable recent work is SoulPad. The SoulPad architecture proposes dividing the computing environment into static carcasses formed by the hardware (denoted in the paper as EnviroPCs) and a mobile “soul.” The mobile soul is implemented using a bootable USB hard disk, composed of an operating system to configure the underlying hardware, and a virtualized operating system on top of it for flexibility to choose between operating systems. The only protection to the portable system is a password which decrypts the virtualized operating system. In the paper, they suggest as future work querying a possible TPM on the EnviroPC for correctness of the BIOS. Other commercial approaches exist to provide portable environments. However none of these approaches, including SoulPad, exploit trusted computing standards.